Requirements governing the development of various types of products have grown as the complexity of these products has increased. Any heterogeneous system (e.g. one built from different types of components) can be defined by a set of requirements documents with which the developed product must comply. Such systems exist in many types of manufacturing and product development such as automotive, military, aerospace, and complex medical systems. Exemplary products may contain such components as computer software programs, computer hardware, semiconductors, mechanical and electrical products, etc. Requirements are often formulated in documents and are partitioned into pieces of text called individual requirements. The requirements are often represented hierarchically.
In requirements management, the refinement and facilitation of requirements are considered in conjunction with the development of a design. The process of requirements specification is an iterative process in which increasingly detailed requirements are produced by the refinement of previously defined requirements. The development of a design generally begins from a set of initial requirements. As the design process progresses, the initial requirements are extended with intermediate design decisions, usually called “derived” requirements. These requirements are added to the whole set of requirements. During the design procedure, further requirements may be elucidated. Managing changes and/or additions to the initial or derived requirements or design often leads to inconsistencies in the requirement and/or design.
Requirements management tools exist some of which are integrated with design management tools. Two exemplary products are DOORS® (available from Telelogic® at http://www.telelogic.com/) and RequisitePro® (available from IBM® Rational® at http://www.ibm.com).
These tools provide basic infrastructure for capturing and selecting requirements, and for connecting requirements to design elements. However, since these tools only allow one general link type between requirements, usually only a simple hierarchy that reflects the structural elements of the requirements document, such as paragraphs, sections, chapters, and enumerations is shown. It is not possible with only one link type to show logical relationships between requirements. A user may wish to assign different roles to links however all the links look the same and there is no way to enter or save such information, hence the user must remember what each link represents.
These tools may also address some primitive forms of impact analysis and traceability problems but the lack of granularity in the definition of relationships prevents an accurate impact analysis from being performed and only step by step tracing between requirements is possible. These tools are further limited in that only whole sets of requirements can be analyzed. There are tools that can determine if all of the requirements are linked to design elements either directly or indirectly, but no analysis is possible on a subset of the requirements.